cmd-build: Refactor to support multiple artifact types #302
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
(This will conflict with #299 - I'm fine rebasing if that lands first) |
|
A few next steps on this:
Proposed target names: |
|
Weren't we moving towards specifying the artifact types we want in an |
I think we may want both; it'd be convenient for development to be able to do e.g. |
|
Per discussion I think we want a |
|
My bad that I didn't see this PR early today, I opened a FCOS ticket on the same topic as this PR: coreos/fedora-coreos-tracker#142 |
cgwalters
force-pushed
the
artifact-types
branch
from
0e1a422 to
83e63bd
Compare
|
Rebased 🏄♂️ though I didn't test the rebase yet. |
cgwalters
force-pushed
the
artifact-types
branch
from
83e63bd to
a83f524
Compare
|
OK now rebased again 🏄♂️ and tested. Would be nice to get this in as the rebase pain is adding up. |
jlebon
reviewed
Feb 5, 2019
cgwalters
force-pushed
the
artifact-types
branch
from
a83f524 to
dfc08ea
Compare
Change the code so that it's prepared to handle e.g.: `coreos-assembler build qemu metal-uefi metal-bios openstack`. There's more work we'll need to do for adding any more image types, this just lays the groundwork.
cgwalters
force-pushed
the
artifact-types
branch
from
dfc08ea to
3da6892
Compare
|
OK, now passing shellcheck. |
jlebon
added a commit
to jlebon/coreos-assembler
that referenced
this pull request
Feb 12, 2019
I'm often just iterating on the OSTree content itself and don't require new images. In such cases, it's a waste of time to wait for images to be generated when all I want is the treecompose. But using `coreos-assembler build` is still more convenient than dropping down to `rpm-ostree compose tree`, especially with the virtualization wrapper. Add a new `--no-images` option in which we only generate a commit to the OSTree repo. This is a natural extension of coreos#302. Crucially though, we still create a build directory under `builds/` with metadata about the built commit. The only practical difference is that there are no image files and no subkeys under `images` in `meta.json`. (I didn't bother breaking the idempotency coupling here wrt the kickstart since (1) it's going away, and (2) this is really just for the local dev case where you're iterating on the tools, like rpm-ostree, or the content, like the treefile.)
jlebon
added a commit
to jlebon/coreos-assembler
that referenced
this pull request
Feb 12, 2019
I'm often just iterating on the OSTree content itself and don't require new images. In such cases, it's a waste of time to wait for images to be generated when all I want is the treecompose. But using `coreos-assembler build` is still more convenient than dropping down to `rpm-ostree compose tree`, especially with the virtualization wrapper. Add a new `--ostree-only` option in which we only generate a commit to the OSTree repo. This is a natural extension of coreos#302. Crucially though, we still create a build directory under `builds/` with metadata about the built commit. The only practical difference is that there are no image files and no subkeys under `images` in `meta.json`. (I didn't bother breaking the idempotency coupling here wrt the kickstart since (1) it's going away, and (2) this is really just for the local dev case where you're iterating on the tools, like rpm-ostree, or the content, like the treefile.)
jlebon
added a commit
to jlebon/coreos-assembler
that referenced
this pull request
Feb 12, 2019
I'm often just iterating on the OSTree content itself and don't require new images. In such cases, it's a waste of time to wait for images to be generated when all I want is the treecompose. But using `coreos-assembler build` is still more convenient than dropping down to `rpm-ostree compose tree`, especially with the virtualization wrapper. Change the concept of `IMAGETYPES` to `TARGETS` and add a new `ostree` target for which we only generate a commit to the OSTree repo. This is a natural extension of coreos#302. Crucially though, we still create a build directory under `builds/` with metadata about the built commit. The only practical difference is that there are no image files and no subkeys under `images` in `meta.json`. (I didn't bother breaking the idempotency coupling here wrt the kickstart since (1) it's going away, and (2) this is really just for the local dev case where you're iterating on the tools, like rpm-ostree, or the content, like the treefile.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Change the code so that it's prepared to handle e.g.:
coreos-assembler build qemu metal-uefi metal-bios openstack.There's more work we'll need to do for adding any more image
types, this just lays the groundwork.