Onboard Alizer

[jasperchui]

Capture activity to onboard Alizer including addressing serviceability, Logging, build system, test automation, release process, code comment, license (EPL->Apache?), etc.

[Remove Deprecated Implementations]

• Remove JS and Java implementation #172
• Remove Java and JS builds and intergration tests from workflow #173
• Update documentation for port detection #185
• Update and re-structure documentation #215

[Update documentation, tests and build processes]

• Update License of Alizer #176
• Enhance logging on go implementation #153
• Add descriptions in public functions and improve code comments #154
• Create test resources for go library and avoid using external repos #155
• Define a release process #151
• Set up build process for release build #186

[Improve functionality]

• Create Proposal for 2.2.x devfile version support #225
• Alizer does not detect port if Dockerfile is not in the root directory #152
• Alizer should be more resilient when detecting ports in a component #146

[Migrate Project]

• Migrate Alizer to Devfiles organization #240

[thepetk]

I'd say the following issues could part of this epic too :)

• Devfile 2.2.x support #159
• Alizer does not detect port if Dockerfile is not in the root directory #152
• Alizer should be more resilient when detecting ports in a component #146

[mike-hoang]

Potential issues for this epic:
After removing js and java implementation, we'll use #177 to remove duplicated resource files to better organize the repo

• Remove JS and Java implementation #172
• Remove Java and JS builds and intergration tests from workflow #173
• Flatten structure of the Project after the removal of JS and Java #177

[thepetk]

This one I'd say too:

• Update go version #182

[elsony]

Other things that can be considered to be added as part of this Epic (feel free to cross out if they are already done):

1. Improve code comments
2. License change from EPL->Apache to align with the devfile project
3. Set up the build system for proper release build
4. Define the communication channels of the project
5. Review existing documentation: identify the gaps and create items to track
6. Set up proper PR test
7. Set up nightly test run that consumes entries in the community devfile registry and product registry - I am ok to move it out to a separate item if we want to reduce the scope of this item

[thepetk]

@elsony , @jasperchui and @mike-hoang I've created/updated all issues.
Re 1: I've updated the #154 to include this action too.
Re 2: We have already created #176 but it wasn't included in this epic. I think this should be done after the onboarding to the new organization (same as #180 for dependabot).
Re 3: Created #186
Re 4: As a part of devfiles team, shouldn't have the same channels?
Re 5: The documentation has been updated with #151 , #149 and we also have the #185
Re 6: For PR testing, we have opened #173 in order to remove all unnecessary checks. We are aiming to keep only the go tests. IMO they are sufficient as we have unit tests for language, devfile, component recognition (additional cases for ports) and e2e tests with the git_test tests.
Re 7: Created #187 (I'd say it can be one of the first issues after the onboarding to devfiles)

After this input the updated list of issues should be:

[Remove Deprecated Implementations]

• Remove JS and Java implementation #172
• Remove Java and JS builds and intergration tests from workflow #173
• Flatten structure of the Project after the removal of JS and Java #177
• Update documentation for port detection #185

[Update documentation, tests and build processes]

• Update License of Alizer #176
• Enhance logging on go implementation #153
• Add descriptions in public functions and improve code comments #154
• Create test resources for go library and avoid using external repos #155
• Define a release process #151
• Set up build process for release build #186

[Improve functionality]

• Devfile 2.2.x support #159
• Alizer does not detect port if Dockerfile is not in the root directory #152
• Alizer should be more resilient when detecting ports in a component #146

WDYT?

[jasperchui]

Re 2: We have already created #176 but it wasn't included in this epic. I think this should be done after the onboarding to the new organization (same as #180 for dependabot).
We should complete this in this EPIC.

[elsony]

Thanks for the updates. The rest looks ok and I only have extra comments for two of them:
4: I am fine with using the devfile communication channel. Having said that, people who finds to the Alizer project currently won't know who and where to contact. We need to have it mentioned somewhere.
6: Do we have test cases for all types of applications that we intended to support? What is the current code coverage?

[thepetk]

@elsony (cc @mike-hoang & @jasperchui)

4: I am fine with using the devfile communication channel. Having said that, people who finds to the Alizer project currently won't know who and where to contact. We need to have it mentioned somewhere.

Maybe I have misinterpreted the issue. I mean that after the onboarding, we can have the same channels as the devfiles. Before that, I'd propose that we can create a dedicated internal channel for this issue (e.g forum-alizer) and for the outerloop I'd say we can continue relying on the github issues. So, any person who want to communicate about alizer they would have to create an issue.

6: Do we have test cases for all types of applications that we intended to support? What is the current code coverage?

I've created the coverage.csv which lists all paths/functions that don't have coverage 100%. The average coverage is: 78.60%.

In order to improve this number I've created the #194 with all cases that are missing from component (and port) & devfile detection.

[michael-valdron]

Could we update the acceptance criteria for this epic to include the additional child issues mentioned in the story?

cc: @thepetk @mike-hoang

[thepetk]

Yes I'll do that soon :)

[thepetk]

I've updated the list of tasks remaining for the onboarding

[thepetk]

I've updated the acceptance criteria for the EPIC. I've removed #226 from the list as it is blocked and the onboarding can be done even if is not completed

[thepetk]

Some details about the final list:

• Devfile 2.2.x support #159 Has been transformed into an epic and removed from the final list. The blocking part for this EPIC is done (Create Proposal for 2.2.x devfile version support #225 and Enhance logging on go implementation #153 )
• Flatten structure of the Project after the removal of JS and Java #177 Was split into two steps ( the part related with onboarding is Migrate Alizer to Devfiles organization #240)