Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a fragment with status of last build #219

Open
costateixeira opened this issue Apr 4, 2023 · 8 comments
Open

Add a fragment with status of last build #219

costateixeira opened this issue Apr 4, 2023 · 8 comments
Assignees

Comments

@costateixeira
Copy link
Collaborator

When looking at an IG, we know it's built ok but we have no idea if the last build failed.
Can we add a fragment that templates can optionally display - next to the publish box? - and show something like
"This spec is up to date" or "The last build failed"... (text tbd)

@costateixeira costateixeira changed the title Add a fragment with status of lasts build Add a fragment with status of last build Apr 4, 2023
@lmckenzi
Copy link
Contributor

lmckenzi commented Apr 4, 2023

How could the current build possibly know that the last build failed?

@costateixeira
Copy link
Collaborator Author

checking the presense of e.g. http://build.fhir.org/ig/WorldHealthOrganization/smart-anc/failure/build.log or something?

@grahamegrieve
Copy link
Contributor

The template can't add a fragment, so this is in the wrong place

@grahamegrieve
Copy link
Contributor

Also, I don't understand how this is useful. if this build succeeds, why does it matter whether the last build failed?

@costateixeira
Copy link
Collaborator Author

The scenario where this is useful is when the build does not succeed - the current page (previous build) should show this somehow

@lmckenzi
Copy link
Contributor

lmckenzi commented Apr 5, 2023

First, don't have a clue how the 'somehow' would work
Second, who would care about this other than the person who's making changes - who can always monitor the Zulip stream.

@costateixeira
Copy link
Collaborator Author

this change is precisely for when one of the people making changes does not check the Zulip stream for one change, or when they cannot fix it, or for non-committers to see the status. If the build gets broken, non-committers will be looking at a broken build without knowing, and the next committers may presume it's their commit that breaks things.

@lmckenzi
Copy link
Contributor

If you have multiple committers, then you might want to look at putting in merge blocking that prevents unsuccessful commits from merging to the master. Non-committers won't be looking at a broken build - they'll be looking at the last successful build. They'll have no idea there are pending changes they don't yet see, and that's probably fine. That's what a CI-build is...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants